Перейти к основному содержимому

6.08. Процесс тестирования

Тестировщику Разработчику Аналитику

Процесс тестирования как управляемая инженерная деятельность

Тестирование — это не хаотичный поиск ошибок, а строго регламентированный процесс, состоящий из последовательных, взаимосвязанных этапов, каждый из которых имеет чёткие входы, выходы и критерии завершения. В стандартах, таких как ISO/IEC/IEEE 29119, тестирование рассматривается как жизненный цикл, включающий пять основных фаз: планирование и контроль, анализ и проектирование, реализация и выполнение, оценка критериев выхода и отчётность, а также деятельность по завершению тестирования.

1. Планирование и контроль

На этом этапе формируется стратегия тестирования — документ, определяющий общий подход к обеспечению качества в рамках проекта. Стратегия включает:

  • цели и приоритеты тестирования;
  • типы и уровни тестирования, которые будут применены;
  • выбранные методы (ручные/автоматизированные);
  • критерии входа и выхода (entry/exit criteria);
  • оценку рисков и распределение ресурсов.

Из стратегии вытекает план тестирования — более детализированный документ, привязанный к конкретному релизу или итерации. Он содержит расписания, ответственных лиц, инструменты, окружения, зависимости и метрики. План тестирования — это живой документ, который корректируется по мере изменения требований или условий проекта.

Контроль осуществляется через регулярный мониторинг прогресса: сколько тест-кейсов выполнено, сколько дефектов открыто/закрыто, соблюдаются ли критерии покрытия, укладываются ли сроки. На основе этих данных принимаются управленческие решения — например, о необходимости расширения покрытия или отсрочке релиза.

2. Анализ требований и проектирование тестов

Анализ требований, описанный ранее, служит основой для проектирования тестовых условий — абстрактных описаний того, что должно быть протестировано (например, «проверка валидации email-адреса при регистрации»). На основе этих условий создаются тест-кейсы — конкретные сценарии с предусловиями, шагами, входными данными и ожидаемыми результатами.

Проектирование тестов использует формальные техники:

  • Эквивалентное разбиение — деление входных данных на классы, в пределах которых система должна вести себя одинаково.
  • Анализ граничных значений — фокус на значениях на границах допустимых диапазонов (минимум, максимум, чуть ниже/выше границы).
  • Таблицы принятия решений — для моделирования логики с множеством условий и действий.
  • Сценарии использования — проверка сквозных пользовательских потоков.

Качественный тест-кейс должен быть однозначным, воспроизводимым, атомарным и независимым от других тестов.

3. Реализация и выполнение

На этапе реализации тест-кейсы преобразуются в исполняемые артефакты:

  • для ручного тестирования — в тест-наборы (test suites) в системах управления тестированием (TestRail, Zephyr, qTest);
  • для автоматизированного тестирования — в скрипты на соответствующих языках и фреймворках.

Выполнение тестов проводится в контролируемых окружениях, соответствующих цели проверки (dev, staging, pre-prod). Результаты фиксируются: успешные и проваленные тесты, возникшие дефекты, временные метки, логи. При выявлении несоответствия создаётся отчёт о дефекте, структура которого включает:

  • краткое название;
  • детальное описание и шаги воспроизведения;
  • ожидаемое и фактическое поведение;
  • окружение (ОС, браузер, версия ПО);
  • скриншоты, логи, видео (при необходимости);
  • приоритет и серьёзность (severity vs priority).

4. Оценка критериев выхода и отчётность

Перед завершением тестирования проводится оценка по заранее определённым критериям выхода, например:

  • 100 % выполнение критических тест-кейсов;
  • отсутствие дефектов блокирующего уровня;
  • покрытие требований — не менее 95 %;
  • стабильность регрессионного набора (не более 2 % нестабильных тестов).

На основе собранных данных формируется отчёт о тестировании (test summary report), который содержит:

  • обзор проведённых работ;
  • метрики (количество тестов, покрытие, плотность дефектов, тренды);
  • выявленные риски;
  • рекомендации по релизу.

Этот отчёт служит основанием для принятия решения о готовности продукта к выпуску.

5. Завершение тестирования

После релиза проводится ретроспектива: анализ эффективности тестовой деятельности, выявление узких мест, обновление репозиториев тест-кейсов и автоматизированных сценариев. Все артефакты архивируются для будущих аудитов или повторного использования.